Speed up cache freshness checks 13–54× on large archives (#12)

Even with a fully warm cache, launching the TUI on a big archive spent seconds
re-verifying freshness. This PR attacks the check itself, benchmarked against a
real 2 GB / 5,381-item copy of ~/.claude/projects (63 projects, ~1,830
session JSONLs, 1,603 sessions).

Results

Warm cache, best of 3, before → after on current main (which already
includes #251):

The --tui launch path runs the freshness check twice (once in
_launch_tui_with_cache_check, again in SessionBrowser.load_sessions), so
the user-visible launch delay was ~1.3 s and is now ~25 ms.

What was actually slow

The file stats were never the problem — stat'ing all 1,830 files takes ~5 ms,
and even a full recursive walk of the 2 GB tree is ~150 ms. The measured costs:

1. A SQLite connection per file. get_modified_files() called
   is_file_cached() per file, each opening a fresh connection (~40× the cost
   of the query it runs). Speed up the SQLite metadata-cache build (connection reuse + synchronous=NORMAL) #251 fixed this pattern for cache builds via
   batch(), but the freshness-check paths don't run inside a batch.
2. Per-file sidecar probes. subagents_fingerprint() (Support hierarchies of agents #213) does an
   is_dir() probe + glob per file, ~160 ms across the archive — almost all
   for files that can't have sidecars.
3. A dead query. get_cached_project_data() ran
   SELECT DISTINCT session_id FROM messages WHERE file_id = ? per cached
   file to fill CachedFileInfo.session_ids — a field nothing reads
   (production code, tests, or docs). This is what made the project selector
   slow.
4. Migration re-checks. Every CacheManager construction re-ran the
   migration check (~2 ms); the TUI selector constructs one per project row,
   on every resize.

Changes (all in cache.py)

• Batched get_modified_files() — one query fetches every cached row for
  the project (one connection open; zero extra inside a batch() scope), and
  one os.scandir per parent directory determines which files even can
  have sidecars, so the fingerprint scan only runs for those (~154 of 1,830
  here). Semantics are identical to the per-file path — verified below.
• Dropped CachedFileInfo.session_ids and its N-queries-per-call.
  (Measured alternatives: single GROUP BY query = 209 ms, per-file lookups
  on a shared connection = 131 ms, not doing it = 4 ms.)
• get_cached_project_data() fetches working_directories on the same
  connection instead of opening a second one per call.
• Memoised the migration check per DB path per process, with an
  exists() guard so --clear-cache's DB deletion still re-migrates.

Connection lifecycle is untouched: connection-per-call stays the default
(the Windows-safe behaviour pinned by #251's integrity tests), and the new
code composes with batch().

Approaches considered and rejected

• Directory-mtime fast path (from the issue): unsound as a freshness
  check — appending to a JSONL doesn't update the directory mtime, so it can
  only detect create/delete/rename. And since per-file stats cost ~5 ms
  total, it would save nothing meaningful.
• Hash-based / probabilistic checking: both optimise the stats, which
  were never the bottleneck; probabilistic is also non-deterministic.
• Parallel scanning / lazy validation: unnecessary at 12 ms; parallelism
  could still help the one-time initial parse (~400 s for the full 2 GB),
  but that's a rare event and separate from this issue.

Verification

• End-to-end change detection on the real archive: touched file detected,
  new sidecar detected (including for a session with no pre-existing
  <stem>/ dir — the case the scandir shortcut could plausibly have
  broken), new file detected, and full parity with per-file
  is_file_cached() both outside and inside a batch() scope.
• 2,323 unit tests + 68 TUI tests pass (including Speed up the SQLite metadata-cache build (connection reuse + synchronous=NORMAL) #251's connection-
  lifecycle integrity tests); ruff check and ty check clean.

Numbers above are from a Linux dev container; absolute values will differ on
macOS but the ratios should hold, since the fix removes work rather than
speeding it up.

Summary by CodeRabbit

• Performance Improvements
  • Significantly faster TUI startup on large archives via batched cache freshness checks and fewer filesystem probes.
  • More efficient cache validation for file updates, including sidecar fingerprint handling.
  • Reduced repeated cache migration work during a single process run.
• Bug Fixes
  • Improved cache metadata rebuilding so changes in project files are reflected more reliably, minimizing stale results.
• Documentation
  • Updated developer documentation to describe the improved cache freshness and cache migration upgrade behavior.